System and method to cause an obfuscated non-functional device to transition to a starting functional state using a specified number of cycles

ABSTRACT

A system and method to cause an obfuscated non-functional device to transition to a starting functional state using a specified number of cycles are disclosed. A particular embodiment includes: an electronic system comprising: a protected electronic device; and an embedded obfuscation unit coupled with the protected electronic device, the embedded obfuscation unit including an obfuscation state machine, the embedded obfuscation unit further including control logic to: obtain a randomized seed value; extract a first number of bits from the randomized seed value, the first number of bits representing an initial obfuscation state; extract a second number of bits from the randomized seed value, the second number of bits representing a starting functional reset state; determine a number of traversal cycles needed to traverse through states of the obfuscation state machine from the initial obfuscation state to the starting functional reset state; and initiate a state traversal operation to traverse through states of the obfuscation state machine from the initial obfuscation state to the starting functional reset state in the determined number of traversal cycles.

PRIORITY PATENT APPLICATION

This is a continuation-in-part patent application claiming priority toU.S. non-provisional patent application Ser. No. 14/716,861, filed onMay 19, 2015; and Ser. No. 14/804,284, filed on Jul. 20, 2015. Thispresent continuation-in-part patent application draws priority from thereferenced patent applications. The entire disclosure of the referencedpatent applications is considered part of the disclosure of the presentapplication and is hereby incorporated by reference herein in itsentirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction of the patent document or thepatent disclosure, as it appears in the Patent and Trademark Officepatent files or records, but otherwise reserves all copyright rightswhatsoever. The following notice applies to the hardware designs,software, and data as described below and in the drawings that form apart of this document: Copyright 2014-2016 Anvaya Solutions, Inc., AllRights Reserved.

TECHNICAL FIELD

This patent application relates to electronic systems, integratedcircuit systems, static electronic devices, mobile electronic devices,electronic hardware and device design, electronic device fabrication,and computer-implemented software, according to various exampleembodiments, and more specifically to a system and method to cause anobfuscated non-functional device to transition to a starting functionalstate using a specified number of cycles.

BACKGROUND

Advances in semiconductor processing and logic design have permitted anincrease in the amount of logic that may be present on integratedcircuit devices. As a result, computer system configurations haveevolved from a single or multiple integrated circuits in a system tomultiple hardware threads, multiple cores, multiple devices, and/orcomplete systems on individual integrated circuits. Additionally, as thedensity and complexity of integrated circuits has grown, the threat ofunauthorized embedded hardware or software components has alsoescalated.

With the Time to Market (TTM) expectancy shortening in recent years,much of the microelectronics supply chain continues to be outsourced.Trust in the supply chain has been greatly eroded due to many differentacts of piracy. This has raised significant questions about theintegrity and authenticity of original Intellectual Property (IP)designs embedded inside an Integrated Circuit (IC) or other electronicdevice.

The following acts of IP piracy have significantly contributed to theerosion of trust in the IC device supply chain: 1) Counterfeiting wherea substandard part, rejected part, or a cannibalized part from apreviously used and discarded board is remarked as new and re-introducedinto the supply chain; and 2) Overbuilding, where the silicon fab housesoverproduce blind copies of the ICs in excess of authorization for theirown spurious sale. Conventional technologies have been unable toeffectively and efficiently provide defenses against these threats.

BRIEF DESCRIPTION OF THE DRAWINGS

The various embodiments are illustrated by way of example, and not byway of limitation, in the figures of the accompanying drawings in which:

FIG. 1 illustrates a system level operational processing flow of anexample embodiment;

FIG. 2 is an architectural diagram illustrating the functionalcomponents provided in the example embodiment;

FIG. 3 is a high level block diagram illustrating the functionalcomponents and processes provided in the example embodiment;

FIG. 4 illustrates the authentication subsystem and authenticationenvironment of an example embodiment;

FIGS. 5 through 8 are flowcharts illustrating an example embodiment ofthe processing operations performed as part of the authenticationprotocol by the authentication subsystem;

FIG. 9 illustrates an example embodiment of the data structuresrepresenting the exchanged device specific authentication information;

FIG. 10 is a processing flow chart illustrating an alternativeembodiment of a method as described herein;

FIGS. 11 through 14 are flowcharts illustrating an example embodiment ofthe processing operations performed for causing an obfuscatednon-functional device to transition to a starting functional state usinga specified number of cycles; and

FIG. 15 shows a diagrammatic representation of a machine in the exampleform of a computing and/or communication system within which a set ofinstructions when executed and/or processing logic when activated maycause the machine to perform any one or more of the methodologiesdescribed and/or claimed herein.

DETAILED DESCRIPTION

In the following detailed description, a reference is made to theaccompanying drawings that form a part hereof, and in which are shown,by way of illustration, specific embodiments in which the disclosedsubject matter can be practiced. It is understood that other embodimentsmay be utilized and structural or process changes may be made withoutdeparting from the scope of the disclosed subject matter.

According to various example embodiments of the disclosed subject matteras described herein, there is provided a system and method to cause anobfuscated non-functional device to transition to a starting functionalstate using a specified number of cycles. The various embodimentsdescribed herein provide an embedded and active obfuscation system,which requires authentication of a protected electronic device aftermanufacturing and prior to any deployment. Once authentication of theprotected electronic device is confirmed, the various embodimentsdescribed herein can activate the protected electronic device by causingthe obfuscated non-functional protected electronic device to transitionto a functional state using a specified number of cycles. This inventivesystem defeats the incorporation of a counterfeit device or anunauthorized overbuilt part into the supply chain. As described herein,the term “device” or “protected electronic device” can refer to amicroelectronic integrated circuit device being protected by the systemsand methods of the various embodiments described herein. In variousembodiments, the protected electronic device can be an integratedcircuit (IC), an electronic system or circuit board, and/or any othertype of electronic device or system.

In a particular described embodiment, every protected electronic deviceperforms a one-time authorization and authentication by the IntellectualProperty (IP) owner (or other authorized representative) to functioncorrectly on a new board or other electronic system into which theprotected electronic device is embedded. Prior to authorization andauthentication, the device can be initially activated (e.g., wake-up) ina unique-per-device obfuscated, non-functional mode on power-on. Thedevice user can then connect with a protected system of the device IPOwner and request the execution of an authentication procedure toconfirm the credentials of the device and the device user. A successfulauthentication will enable the IP Owner to issue an authentication keyto the device user, which enables a transition of the operational modeof the device from the initial obfuscated, non-functional mode to afunctional mode. The various embodiments described herein provide anembedded hardware method integrated in a per-device unique fashion, fortransitioning the device from the non-functional obfuscated mode to thefully functional device mode.

Based on the inventive approach offered by the various embodimentsdescribed herein, the following advantages can be realized:

-   -   Any electronic device protected by the obfuscation technology        disclosed herein will be rendered non-functional after        manufacturing and prior to authentication. The protected        electronic device will require a one-time per board/system        authentication by the IP owner (or other authorized        representative) for the device to be operationally functional.    -   Such an authentication cannot be transferred to a different        board/system, which therefore prevents unauthorized reuse of the        protected device.    -   Similarly, a counterfeit part deployed for unauthorized reuse        remains functionally dead, as it will not be authenticated by        the IP owner (or other authorized representative) for such        unauthorized reuse.

The electronic device authentication and enablement system and methoddescribed herein eliminates the cumbersome burden of first detecting andthen proving a spurious device in play in the supply chain. By use ofthe obfuscation technology disclosed herein, the producer, fabricator,or the end user of such a spurious device must first contact the IPowner to enable the device to function. By requiring this deviceauthentication prior to use, the possessor of the spurious device islikely to be caught and most likely such an overbuilt/counterfeit devicewill remain inactive and prevent any damage to the supply chain. Thedeployment of an overbuilt or counterfeit part into the supply chainitself is thwarted, as such a part is rendered useless untilauthenticated. The systems and methods of the various embodimentsdescribed herein enhance the trustworthiness of the device in play inthe supply chain, even as many of the elements in the supply chainremain untrustworthy. This should be compared against the currentpassive methods where there are no countermeasures to prevent therelease of the spurious parts into the supply chain or, their eventualuse in an end product (because they slipped through and never gotdetected). The conventional methods of post-deployment passive detectioncan therefore result in serious damage, possibly catastrophic damage,once the spurious part is fielded for use.

A fundamental goal of the various embodiments described herein is tohave the protected electronic device converge from its native wakeupobfuscated mode to the starting functional reset mode in the specifiednumber of clock cycles. The transition to a functional mode should nottake more than the pre-determined number of cycles; because, anexcessive number of cycles may violate the performance metric of thedevice. The transition to a functional mode should not take less thanthe pre-determined number of cycles; because, an insufficient number ofcycles may dilute the obfuscation strength and thus the integrity of thedevice. A goal of the various embodiments described herein is to embedreal confusion and deception into the operation of the device andthereby obfuscate the nefarious understanding or prediction of how thedevice transitions into the functional mode.

It is quite easy to design a device that can reach an initialfunctioning state from any obfuscated state in a very quick anddefinitively-timed manner. However, any observation of such a quick,predictable convergence to the functional start state will make it easyfor a hacker to tamper or reverse-engineer the device to completelybypass the obfuscation logic and thus defeat the authentication process.The meandering traversal each device uniquely attempts through differentstate transition paths to finally reach its first functioning statefacilitates confusion in understanding the device behavior. Thisconfusion in understanding enhances the protection of the device IP. Tobind the traversal path time for a particular device, the authenticationkey (from the IP Owner) sets a parameter to specify the time to beactually taken to perform the traversal from an obfuscated,non-functional state to the initial functional state.

Several important elements of an example embodiment of the method, whichreinforces the layer of obfuscation while moving the device to afunctional mode, include the following:

-   -   Every microelectronic device has a sea-of-states (e.g., a large        plurality of states) defining a master control state machine        (and also other lower state machines if desired). The bulk of        the states in the large plurality of states constitutes the        obfuscated logic, which renders the device non-functional. The        small remainder of the states in the large plurality of states        constitutes the functional logic, which renders the device        functional and allows for normal device behavior. Typically for        effective obfuscation, the ratio of the obfuscated-states count        to functional-states count should be a million-to-one or more.        This can be implemented with very little design overhead by        increasing the width of total state machine state bits (e.g.,        flops). For example, a state machine with a million states can        be easily realized using 20 flops to define the 2²⁰ or million        states. In practice, the width of the state machine state bits        should be even larger and in the range of 22 to 32 bits to        provide a total state machine state count between 4 million to 4        billion states. The number of functional states on the other        hand is typically only between 4 to 16 states. Thus, the desired        large ratio of obfuscation states to functional states can be        easily realized using the techniques disclosed herein.    -   The initial traversal through the large number of obfuscation        states to reach the starting functional state happens during a        mode denoted as the, “Convergence Window” time. During this        traversal, it is possible to hit some of the very few functional        states; however, encountering a functional state during the        traversal while in an active “Convergence Window” configured        mode, will have no impact on the traversal, which will continue        to proceed. This “Convergence Window” mode configures all        functional states to be dormant during this initial traversal.        Once the convergence to the first starting functional state is        accomplished, the “Convergence Window” mode closes and all        functional states will start exhibiting normal functional        behavior.    -   Every device wakes up in a unique obfuscated starting state,        which keeps the device non-functional. The uniqueness per device        is guaranteed by Physically Unclonable Function (PUF) circuitry        and other techniques at the device-specific granularity.    -   Each microelectronic device also has a uniquely defined initial        or starting Functional Reset state. The uniqueness for each        device regarding where its functional starting state is located        among the sea-of-states (as defined by state flops value) is        again influenced by the device-specific embedded features, such        as PUF, etc.    -   Additionally for each device, the rest of the very few        functional states will also be uniquely scattered among the        sea-of-states. The scattering of these functional states        differently among the devices is also determined by        device-specific parameters.    -   The burying of the few functional states amidst a sea of        obfuscated states through a flat logic hierarchy, as well as the        blending of subsequent transitions among all states in a        non-obtrusive manner, ensures the seamless behavior of the        entire state machine logic both during obfuscated mode as well        as in functional mode. This makes the understanding of the        obfuscation behavior itself (to render it ineffective), very        difficult for reverse-engineering or copying.

Referring now to FIG. 1, the diagram illustrates a system leveloperational processing flow of an example embodiment. The electronicdevice authentication and enablement system and method described hereinis active, always-on, and built into the protected electronic systemdesign. The example embodiment allows for the protected electronicdevice to wake-up on power-on in a non-functional obfuscated mode whenthe protected device is paired with a new board/system for the firsttime (see FIG. 1, block 210). As described in more detail below, theexample embodiment generates a device and context unique obfuscationcode (see FIG. 1, block 220) and uses the obfuscation code to request acorresponding authentication key from an IP owner or authorizedrepresentative of the protected electronic device (see FIG. 1, block230). The authentication key can be provided to the protected electronicdevice after the IP owner successfully verifies the credentials of theprotected electronic device. The authentication key received by theprotected electronic device can be used to restore the protectedelectronic device to a fully operational mode (see FIG. 1, blocks240-260).

For an authorized use of a protected device on or with a specificboard/system, a one-time handshake (e.g., data communication) between anIP owner of the protected device and a device manufacturer/end-user isrequired to enable the protected device to be functional. In an exampleembodiment, a Physically Unclonable Function (PUF) device is used togenerate a first portion of an obfuscation code used to authenticate theprotected device. Physically Unclonable Function (PUF) devices arewell-known physical entities that can be embodied in a physicalstructure and provide output that is easy to evaluate, but hard topredict. Further, an individual PUF device is typically easy to make,but its results are practically impossible to duplicate, even given theexact manufacturing process that produced it. In this respect, a PUFdevice is the hardware equivalent of a one-way function.

In an example embodiment, at power-on, each protected electronic deviceexhibits a unique per device internal n bit value or code, whichrepresents a first portion of an obfuscation code uniquely associatedwith the protected device in the particular system. The n bit value orcode gets created based on the manufacturing or physical characteristicsof the protected device. In the example embodiment, the n parameter canbe pre-defined, so the length of the first portion of the obfuscationcode can be pre-defined. In a particular embodiment, the length of thefirst portion of the obfuscation code is 84 bits, where n=84. In oneexample embodiment, this first portion of the obfuscation code can begenerated using a delay, or static random access memory (SRAM) basedPUF, along with the associated error correcting code logic (ECC).Alternatively, in another example embodiment, the first portion of theobfuscation code can be generated by n bits of fuse, which are randomlyprogrammable per device on the manufacturing floor. It will be apparentto those of ordinary skill in the art in view of the disclosure hereinthat other equivalent methods can be used to generate a value, unique toa protected device in a particular system, which can represent the firstportion of the obfuscation code.

In the example embodiment, a second portion of the obfuscation code canbe generated from a combination of one or more other parameters,register contents, data items, or values, including a unique deviceidentifier (ID) associated with the protected device, a unique devicemanufacturing lot ID, a unique purchase order or contract ID, a uniquepart ID of the board or system used, a unique time/date stamp of thedevice manufacture, an ID associated with the geographic location of themanufacture, a unique system context ID, a unique ID of the devicemanufacturer or IP owner, a digital signature, a watermark, a digitalrights management data object or ID, any other device specificinformation from the manufacturer, and any other design specificinformation from the IP owner. It will be apparent to those of ordinaryskill in the art in view of the disclosure herein that other equivalentvalues can be used in a combination of values, which can represent thesecond portion of the obfuscation code.

In the example embodiment, the first portion of the obfuscation code asdescribed above can be combined with the second portion of theobfuscation code as also described above to form a combined obfuscationcode, or simply, the obfuscation code. When the protected device and theboard/system are paired for the first time, the protected device canread the device-unique obfuscation code (see FIG. 1, block 220). Theobfuscation code, as generated by the example embodiment, can representa unique value associated with the particular protected device in thecontext of a particular board/system installation and manufacturingparameters. In an example embodiment, the obfuscation code can be aunique 128 bit pattern or value created with the combination componentsub-values as described above. In alternative embodiments, the length ofthe obfuscation code can be lengthened or shortened to conform to aparticular implementation. Additionally, the initially generatedobfuscation code can be hashed or otherwise processed to produce anobfuscation code with desired characteristics. In an embodiment, theobfuscation code can be stored into secured Basic Input/Output System(BIOS) code, stored into a Tamper Resistant on-board Flash memorydevice, or stored into a Trusted Platform Module (TPM). In anotherembodiment, the obfuscation code can be stored into an Obfuscation StateRead Only Register. In another embodiment, the obfuscation code is notstored on the board/system, but rather generated in real-time when theboard/system is booted up (powered up or restarted).

As described in detail below in connection with a particular exampleembodiment, obfuscation technology as described herein enables aone-time authentication of the protected device in the context of theparticular the board/system installation and manufacturing parameters.When a protected device and a board/system are initially paired andpowered up, the example embodiment can perform the one-timeauthentication process. As an initial part of this process, theobfuscation code is generated as described above. Next, the obfuscationcode can be read from the protected device or obfuscation components byan external system. The external system can be a network-connectedcomputer or other separate processing platform. The external system canestablish independent data communication with an IP owner or authorizedrepresentative associated with the protected device. The external systemcan send the obfuscation code read from the protected device to acomputing system of the IP owner with a request for a deviceauthentication key (see FIG. 1, block 230). Using any of a variety ofwell-known data processing techniques, the computing system of the IPowner can generate a device-unique authentication key based on theobfuscation code read from the protected device. In a particular exampleembodiment, the computing system of the IP owner can generate thedevice-unique authentication key using conventional techniques, such asencryption, steganography, hashing, or other data processing techniques.As a result, a device-unique authentication key based on the deviceobfuscation code can be generated by the IP owner or authorizedrepresentative associated with the protected device. The authenticationkey can be specific to the protected device in the context of theparticular the board/system installation and manufacturing parameters.Thus, the IP owner can control the manufacture and usage of theparticular protected device. In an example embodiment, theauthentication key can be a 128 bit value derived from the deviceobfuscation code. In other alternative embodiments, the length of theauthentication key can be configured to conform to a particulardevice/system implementation.

Once the device-unique authentication key is generated by the IP owneror authorized representative as described above, the authentication keycan be provided to the protected device and/or obfuscation components ina data communication from the external computing system of the IP owner,after the IP owner successfully verifies the credentials of theprotected device (see FIG. 1, block 240). In an example embodiment, theauthentication key received from the IP owner can be verified orvalidated by the protected device to confirm that the receivedauthentication key is authentic. The validated authentication keyreceived from the IP owner can be programmed into the protected deviceand/or obfuscation components (see FIG. 1, block 250) and used by theobfuscation state machine of the example embodiment to render theprotected device functional in the manner described in more detail below(see FIG. 1, block 260). For subsequent retrieval and use of theprotected device on the same board/system during subsequent power-oncycles or boot-ups, the returned authentication key from the IP owner isembedded with elements of the first portion of the obfuscation code(derived from the device unique embedded n parameter bits), and then canbe stored on the authorized board/system, such as stored into securedBIOS code, a Tamper Resistant on-board flash memory, or a TrustedPlatform Module (TPM) and loaded from there (see FIG. 1, block 270). Anon-resettable “Valid Authentication Key Programmed” flag can be set toindicate the presence of the validly programmed authentication key. Inthe example embodiment, the data exchange between the protected deviceand the IP owner occurs only once, at the very first time the protecteddevice is paired with a specific board/system. In the exampleembodiment, there is no need for a subsequent authentication queryexchange between the protected device and the IP owner, as long as theprotected device is paired with the same board/system.

Referring now to FIG. 2, an architectural diagram illustrates thefunctional components provided in the example embodiment. In a typicalelectronic system design, a functional/operational electronic device orsystem (denoted protected device) 330 for a particular board or system305 can be developed and defined in a variety of forms. For example, adigital system design can be defined as a Register-Transfer-Level (RTL)abstraction as used in hardware description languages (HDLs) likeVerilog and VHDL to create high-level representations of a circuit, fromwhich lower-level representations and ultimately actual wiring can bederived. Design at the RTL level is typical practice in modern digitaldesign. A digital system design, such as functional/operational system330, can also be defined as a netlist. A netlist describes theconnectivity of an electronic design. As such, a single netlist is alist of all the component terminals that should be electricallyconnected together for the circuit to work. The design offunctional/operational system 330 can also be defined in a variety ofother forms as well. In any of these design definition forms, the designof functional/operational system 330 can be integrated with or embeddedwith the design of the embedded active obfuscation unit 300 as describedherein in various embodiments. As a result, the embedded activeobfuscation unit 300 can be embedded into the design and functionalityof the functional/operational system 330 using any of the designdefinition forms in which the functional/operational system 330 isdefined. As a result, the embedded active obfuscation unit 300 and thefunctional/operational system 330 can be integrated very early in thedesign process and before the functional/operational system 330 designgets exposed to the threats described above.

Referring still to FIG. 2, the embedded active obfuscation unit 300 ofthe example embodiment can include a Physically Unclonahle Function(PUF) 310 and error correcting code logic (ECC) 312. As described abovefor an example embodiment, PUF 310 can be used to generate a firstportion of the obfuscation code which is used to authenticate thefunctional/operational system or protected device 330. In one exampleembodiment, the first portion of the obfuscation code can be generatedusing a delay, or SRAM based PUF 310, along with the associated ECC 312.

The embedded active obfuscation unit 300 of the example embodiment caninclude device/board identifier and manufacturing data component 314. Inthe example embodiment, a second portion of the obfuscation code can begenerated from a combination of one or more other parameters, registercontents, data items, or values, retained by the device/board identifierand manufacturing data component 314. These parameters can include aunique device identifier (ID) associated with the protected device, aunique device manufacturing lot ID, a unique purchase order or contractID, a unique part ID of the board or system used, a unique time/datestamp of the device manufacture, an ID associated with the geographiclocation of the manufacture, a unique system context ID, a unique ID ofthe device manufacturer or IP owner, a digital signature, a watermark, adigital rights management data object or ID, any other device specificinformation from the manufacturer, and any other design specificinformation from the IP owner.

Referring still to FIG. 2, the embedded active obfuscation unit 300 ofthe example embodiment can include an obfuscation state register 316 andan authentication key register 318. The obfuscation code, as generatedby the example embodiment, can represent a unique value associated withthe particular protected device in the context of a particularboard/system installation and manufacturing parameters. In an exampleembodiment, the obfuscation code can be a unique 128 bit pattern orvalue created with the combination of component sub-values as describedabove. In one embodiment, the obfuscation code can be stored intoobfuscation state register 316 and is regenerated every time at power-onfor use. The device-unique authentication key is generated by the IPowner or authorized representative based on the device obfuscation codeas described above. The authentication key can be provided to theprotected device via an external system. Once the device-uniqueauthentication key is received by the embedded active obfuscation unit300, the authentication key can be stored in authentication key register318, and after being combined with the elements of the first part of theobfuscation code, is also updated into the secure BIOS code, or storedin an encrypted fashion either into a Tamper Resistant on-board Flashmemory device, or into a Trusted Platform Module (TPM). The storedauthentication key can be retrieved and used on the same board/systemduring subsequent power-on cycles or boot-ups of the protected device330, and thus the need for query/exchange with the IP owner is obviated.

Referring still to FIG. 2, the embedded active obfuscation unit 300 ofthe example embodiment can include an obfuscation state machine 320, avalid authentication key programmed flag 319, and a functional statereached flag 322. As described in more detail below, the embedded activeobfuscation unit 300 can use the authentication key to cause theobfuscation state machine 320 to transition through a pre-definedsequence of obfuscation (non-functional states) states to reach astarting functional reset state, which enables the protected device 330to enter a functional or operational mode. Once this functional oroperational mode is reached, the functional state reached flag 322 canbe set to indicate the active functional state. This flag enables theprotected device 330 to verify that the proper device authenticationprocess has been completed successfully and that the device is in anormal functional mode.

Referring now to FIG. 3, a high level block diagram illustrates thefunctional components and processes provided in the example embodiment.As shown, the example embodiment includes the physical unclonablefunction (PUF) 310 and error correcting code logic (ECC) 312. Asdescribed above for an example embodiment, PUF 310 can be used togenerate a first portion of the obfuscation code, which is used toauthenticate the protected device 330. In one example embodiment, thefirst portion of the obfuscation code can be generated using a delay, orSRAM based PUF 310, along with the associated ECC 312. In the exampleembodiment, the PUF 310 can generate a unique but consistent PUF basedID for each electronic device. The unique PUF value can be generatedusing device manufacturing or physical characteristics, which produceunique internal path delays leading to unique storage values in internalstorage elements. The PUF 310 can be a Delay-Arbiter type based device,or can be based on the aggregation of un-initialized wake-up contents ofall the storage cells of an on-chip SRAM. Alternatively, in anotherexample embodiment, the first portion of the obfuscation code can begenerated by n bits of fuse, which are randomly programmable per deviceon the manufacturing floor. This alternative embodiment is shown in thebottom left portion of FIG. 3. In the example embodiment shown, 84 fusewires can be used to program a random value for each protected device,thus providing (2⁸⁴) unique device IDs. For the integrity of thisapproach, the fuse programming/blowing can be performed at a silicontesting facility within the IP owner's control, using a true entropyseed feeding into a pseudo-random number generator.

As described above, the second portion of the obfuscation code can begenerated from a combination of one or more other parameters, registercontents, data items, or values, retained by the device/board identifierand manufacturing data component 314. The first portion of theobfuscation code from the PUF/fuse function can be augmented with thesecond portion of the obfuscation code comprising several other deviceand board specific manufacturing parameters to create the obfuscationcode representing a native wake-up obfuscation state signature of thedevice. In an example embodiment, the obfuscation code can be a 128 bitvalue to enable encryption. It will be apparent to those of ordinaryskill in the art in view of the disclosure herein that the obfuscationcode can be any desired length as needed for particular applications.This obfuscation code can be read out by an external user system on thefirst pairing of the protected device and the board/system. Theobfuscation code may optionally be further encrypted, if required, usingstandard encryption methods before the obfuscation code is read out.

The information retained by the device/board identifier andmanufacturing data component 314 and used for the second portion of theobfuscation code can be used by the IP owner for several reasons. First,the reporting of the unique device ID by the manufacturer/device user,by itself, can be used to update the manufactured silicon count and thusto thwart any overbuilding attempt by a fabrication house. Secondly,once the pairing of the protected device to a board/system is reported,any future pairing of the same device (ID) with another board/system canbe further investigated to determine if the new usage is for a remarkedcounterfeit part usage attempt. Then, such an entry of a counterfeitpart into the supply chain can be prevented. A legitimate use of arefurbished part on a new board/system by an authorized supplier, willhowever, be approved by the IP owner with a new authentication afterchecking the certified credentials of the authorized supplier.

Referring to the lower portion of FIG. 3, once the obfuscation code isgenerated as described above, the user of the protected device can usean external system to forward the generated obfuscation code to a systemof the IP owner with a request for an authentication key. In the exampleembodiment, the external system of the protected device user cancommunicate with the IP owner's system via a generic web-based secureprotocol.

Referring to the lower right portion of FIG. 3, in response to thereceipt of the obfuscation code and the request for an authenticationkey from the external system of the protected device user, the IP ownerwill first verify the device user supplied credentials and establish thetrust of the device. Based on the device trust validation, the IP ownercan generate and send the corresponding authentication key to the systemof the protected device user through the same secure web protocol. In aparticular embodiment, the data communication between the protecteddevice user system and the IP owner system can be an encrypted 128 bitdata transmission for added security. Upon receipt of the authenticationkey at the protected device, the authentication key can be programmedinto the obfuscation state machine 320 of the embedded activeobfuscation unit 300. In the example embodiment, the authentication keyserves as the unique key to unlock the functionality of the specificprotected device 330. Because the authentication key is derived from thedevice-unique obfuscation code as described above, the authenticationkey has a direct relationship with the unique wake-up protocol and theunique obfuscation state of the protected device 330.

Referring to the upper right portion of FIG. 3, the embedded activeobfuscation unit 300 can use the previously generated obfuscation codeto populate a pre-defined quantity of state elements (denoted stateflops in FIG. 3) for obfuscation state machine 320. Each state elementcan represent an obfuscation (non-functional) state or a functionalstate of the protected device 330. In the example embodiment, theobfuscation unit 300 can select a portion of the obfuscation code, thelength of which corresponds to the pre-defined quantity of stateelements. In a particular embodiment shown in FIG. 3, the pre-definedquantity of state elements is 2^(k), which can be a variable number ofstate elements designed to meet security requirements. As such, theobfuscation unit 300 can select k bits from the obfuscation code torepresent the portion of the obfuscation code that corresponds to the2^(k) state elements as shown in FIG. 3. In a particular embodiment, thek bits can be selected from random bits of the obfuscation code field.In other embodiments, a particular bit selection pattern can be used. Inthe example embodiment, a pre-defined quantity (kf or k′) of the k statebits can correspond to 2^(k′) functional state elements of the protecteddevice 330. The remaining quantity (k−kf=ko) of the k state bits cancorrespond to 2^(ko) obfuscation or non-functional state elements of theprotected device 330. It is desired that the quantities k and ko besubstantially greater than the quantity kf so the functional states canbe well hidden among a huge plurality of obfuscation or non-functionalstates of the protected device 330. In a particular embodiment, thevalue k can be an order of magnitude greater than the value of kf, sothat the quantity of total state elements 2^(k) is three to twelveorders of magnitude greater than 2^(kf), the quantity of totalfunctional state elements. In the example embodiment, the pre-definedquantity of functional state elements, 2^(kf), can be driven by design.

In the example embodiment, the k bits selected from the obfuscation codeby the obfuscation unit 300 can be loaded into the k state flops of theobfuscation state machine 320. In a particular embodiment, the k bitsselected from the obfuscation code by the obfuscation unit 300 can beloaded into Boosted State Transition Graph (BSTG) flip-flops (e.g.,state elements) of the obfuscation state machine 320. As a result of thek state flops of the obfuscation state machine 320 being loaded with theportion of the obfuscation code as described above, the obfuscationstate machine 320 is configured to define a total of 2^(k) states. Giventhe quantity kf of functional state elements as described above, theobfuscation state machine 320 is also thereby configured to define atotal of 2^(kf) functional states. As explained above, the quantity oftotal states 2^(k) is substantially greater than the quantity offunctional states 2^(kf) in the obfuscation state machine 320.

Because the content of the obfuscation code for a particular system canbe controlled by the configuration of the PUF 310 and the othercomponents of the obfuscation code, the content of the obfuscation codecan be configured to cause the obfuscation state machine 320 toinitially enter an obfuscation or non-functional state. Given theinitial obfuscation state, the protected device 330 will start up onpower-up or reset in an initial obfuscation state. As such, theprotected device 330 is forced to transition through a pre-defined setof obfuscation states before reaching a functional state for normaloperation.

As described above, the obfuscation state machine 320 can be configuredwith 2^(k) total states using k state bits and a substantially fewerquantity of 2^(kf) functional states using kf functional state bits. Asalso described above, the particular configuration of 2^(k) total statesand 2^(kf) functional states in the obfuscation state machine 320 isderived from the value represented by the obfuscation code. As describedabove, the obfuscation code represents a unique value associated withthe particular protected device 330 in the context of a particularboard/system installation and device manufacturing parameters. Theobfuscation code for a particular protected system 330 is transferred toand used by the IP owner to generate the authentication key for theparticular protected device 330. Because the particular configuration ofstates and functional states in the obfuscation state machine 320 isderived from the obfuscation code, the authentication key can bemathematically related to the obfuscation code and thus related to theparticular configuration of states and functional states in theobfuscation state machine 320. As a result, the authentication keygenerated by the IP owner can represent a mapping or a particularsequence or pattern of state transitions to cause the obfuscation statemachine 320 to transition from the initial obfuscation state, through aplurality of intermediate states, to a starting functional reset statefor the protected system 330. The authentication key can be provided orprogrammed into the obfuscation state machine 320 of the obfuscationunit 300. Thus, the protected system 330 is unlocked with theauthentication key and can transition from the initial obfuscation stateto a starting functional reset state from which the protected system 330can begin secure, normal operation. In a particular embodiment, theauthentication key may also specify the required number c of clockcycles to be used for the protected system 330 to move from theobfuscated state to the functional state. The value of c in a particularembodiment can be a configurable parameter by the IP owner as part ofthe authentication key. Based on the value of c used in an embodiment, astep up/down counter with a base-line increment/decrement per clock canbe created inside the device. This enables the obfuscation state machine320 to transition across the number of states to reach the eventualstarting functional reset state, all around the required number c ofclock cycles.

In the event the total number of obfuscated states 2^(ko) is very large(e.g., twelve orders of magnitude larger) compared to the quantity oftotal functional states 2^(kf), the logic cone of input signals leadingto the starting functional reset state will be very large, leading topotential circuit timing delay problems.

This issue can be mitigated by duplicating several functional resetstates in place of one starting functional reset state. All of thesefunctional reset states can be configured to converge and transition toother single or duplicated functional states. The use of replicatedfunctional states and multiple functional reset states can overcomecircuit timing delay problems caused by the use of a large quantity ofobfuscated states 2^(ko) in various embodiments.

As described above, the obfuscation state machine 320 is configured touse the authentication key to cause transition from the initialobfuscation state, through intermediate states as specified by thenumber c of clock cycles, to one of potentially multiple startingfunctional reset states for the protected system 330. Once theobfuscation state machine 320 reaches a starting functional reset state,the obfuscation state machine 320 will thereafter transition only withinthe set of functional states, even after a hardware reset, and willnever transition to a non-functional obfuscation state until the nextpower-on cycle. As a result, the obfuscation unit 300 is configured tosecurely cause the protected system 330 to reach a starting functionalreset state and normal, secure operation thereafter. Once the protectedsystem 330 transitions to a functional state, a Functional State Reachedflag can be set to indicate the completion of the transition from theobfuscation state. This flag is available for other system components toverify that the protected device 330 has been properly authenticated. Ina particular embodiment, it will take a minimum of 256 native, protecteddevice clock cycles at the protected device clock speed to put theprotected device into a secure, functional operational mode on everypower-up cycle.

In an alternative embodiment, each of the state bits in the obfuscationstate machine 320 can be configured to define more than two states.Instead of using conventional flip-flops that define only two states: 1)functional, or 2) non-functional, other multi-state devices may be usedfor the state bits in place of two-state flip-flops to define valuescorresponding to an arbitrary quantity of states, x, for each state bit.In this embodiment, the use of k state bits would enable theconfiguration of x^(k) states in the obfuscation state machine 320. Suchan embodiment can substantially increase the quantity of obfuscationstates relative to the quantity of functional states and provide anincreased level of security.

Authentication Protocol in an Example Embodiment

In an example embodiment described herein, an authentication protocol isprovided for use by the IP owner to first verify the genuineness of aprotected electronic device and then to authorize the protected deviceto be functional in a particular electronic system. Until such anauthorization is provided, the protected electronic device will remainnon-functional when paired with the particular electronic system, suchas an electronic board. The authentication protocol as described hereinuses a full handshake protocol between a user of the protectedelectronic device and the IP owner of the protected electronic device toprovision the authentication of the protected electronic device in aparticular electronic system.

In the example embodiments described herein, an authentication protocolcan authenticate a protected electronic device based on indicia of thedevice's genuineness and indicia of a pairing of the protectedelectronic device with a particular electronic system. When a protectedelectronic device is first paired with a particular electronic system,the authentication protocol of an example embodiment can perform severalauthentication operations to gather and validate the indicia of thedevice's genuineness and indicia of a pairing of the protectedelectronic device with a particular electronic system. For example, theauthentication protocol of an example embodiment can determine when theprotected electronic device is first paired with a particular electronicsystem. On the first such pairing, information can be recorded todocument the new pairing. As a result, subsequent pairings between thesame device and system can be identified and a less extensiveauthentication process can be used.

The authentication protocol of an example embodiment can also check andcatch attempts to use a previously authorized protected device on a newspurious electronic system (e.g., board). In this manner, anunauthorized pairing between a previously authorized device and anunauthorized system can be prevented. However, in some cases, it may beappropriate to allow the pairing of a previously authorized device on anew electronic system. For example, a refurbished device may have beenpreviously authorized. It may be appropriate to allow a refurbished andpreviously authorized device to be paired with a new system. Theauthentication protocol of an example embodiment can determine if adevice is a previously authorized and refurbished device. In this case,the authentication protocol can authorize the pairing between theauthorized refurbished device and a new system, once the credentials ofthe refurbishing house (e.g., the party responsible for the refurbisheddevice) are established and confirmed.

The authentication protocol of an example embodiment can also detect ifthe electronic device itself is an unauthorized clone, a fab-overbuiltpart, or a remarked chop-shop part. On such detections, the IP owner,using the authentication protocol of an example embodiment, can chooseto not authenticate such an electronic device and the device will remainfunctionally inactive if paired with a system/board. In an exampleembodiment, the authentication protocol can use secure reference designsand validated hardware solutions to compare against the informationprovided by an electronic device user seeking to obtain authenticationof a particular electronic device. These comparisons can be used toidentify unauthorized devices and to establish a level of trust withauthentic devices. Once trust is established by the authenticationsubsystem of an example embodiment using the authentication protocol asdescribed herein, an authentication key can be generated by the IP owneror an IP owner key provisioning end-point (e.g., an authenticationprovisioning node).

As part of the authentication protocol of an example embodiment, theauthentication protocol ensures that the protected device provider/useris compelled to connect with the IP owner of the protected device and toobtain device authentication and device/system pairing authenticationprior to enabling the functionality of the device in a particularsystem. As a result, the device provider/user will face increasedscrutiny if suspicions are raised about the authenticity of the device.Until such doubts are cleared, the authentication to enable thefunctioning of the device can be denied, rendering the devicenon-functional on the particular system/board.

The authentication protocol of an example embodiment uses a structuredinformation exchange between the provider/user of the protectedelectronic device and the IP owner corresponding to the protecteddevice. Referring to FIG. 4, a networked authentication environment 400in an example embodiment is illustrated. The authentication protocol ofan example embodiment uses two parties or two computing nodes for theauthentication: 1) the device provider/user and a computing system 410of the device provider/user at a first node (denoted as the requestingdevice node or RDN 410), and 2) the IP owner and a computing system 420of the IP owner at a second node (denoted the authenticationprovisioning node or APN 420). Using conventional secure computing andnetworking technologies (e.g., the Internet 405), any deviceprovider/user node 410 can connect (e.g., establish a datacommunication) with the IP owner's authentication provisioning node 420.Once this connection is established, the requesting device node 410 canprovide device 330 and system/board 305 details required by theauthentication provisioning node 420 to complete the authentication. Insome cases, additional device 330 details, if required, can be providedby the device provider/user node 410 in an out-of-band communication424.

Referring still to FIG. 4, the authentication subsystem 422 of anexample embodiment, using the authentication protocol as describedherein, can perform trust verification, device authentication, andauthentication key provisioning in an automated manner. The IP owner'sauthentication provisioning node 420 can perform the automated trustverification, device authentication, and authentication keyprovisioning, based on the information provided by the requesting devicenode 410. The authentication provisioning node 420 can use theinformation provided by the requesting device node 410 to determine thegrant or denial status of the device authentication key for therequesting device node 410. This method can also provide for subsequentresolution of any issue by mandating the device provider/user's directand active participation/communication with the IP owner. After aninitial successful authentication, the protected device 330 can beauthenticated for subsequent power-on cycles and re-boots of the sameprotected device 330 on the same system/board 305 without performing afull authentication sequence with APN 420 as described above.

The authentication subsystem 422 of the example embodiments provides theassurance that a protected device 330 will never be enabled to functionin an unauthorized manner. Such an expectation is very pronounced andhighly demanded in mission critical applications, for example, in therealm of the defense industry, Department of Defense (DoD), NASA, andnew technology sectors, including the Internet of Things (IoT),automotive applications, aerospace applications, and bio-medicaldevices. The authentication subsystem 422 described herein provideswide, pro-active coverage against several IP and IC piracy techniques,which are currently detected only by passive and reactive methods afterthe deployment of the pirated part. The authentication subsystem 422 ofthe example embodiments provides an opportunity for low cost deviceauthentication based on early detection and prevention of the entry of aspurious part into the supply chain. The authentication protocolrequiring a device user to obtain an authentication key from an IP ownerdefeats most of the current methods used in IP and IC piracy and offersprotection against them. The authentication subsystem 422 describedherein provides the assurance of the genuineness of the electronicdevices in play.

Referring now to FIGS. 5 through 8, an example embodiment illustratesthe processing operations performed as part of the authenticationprotocol by the authentication subsystem 422. As described herein, theauthentication protocol of an example embodiment includes a datacommunication between the protected device provider/user using theprotected device on a specific system or board for the very first timeand the protected device IP owner. A successful authentication betweenthe protected device provider/user and the device IP owner is requiredto unlock the obfuscated device and to make the protected devicefunctional on the specific system/board.

As described herein, the authentication protocol of an exampleembodiment uses two computing nodes for the authentication: 1) therequesting device node 410, and 2) the authentication provisioning node420. Therefore, the two parties involved in the authentication protocolof the example embodiment are:

-   -   The IP Owner who wants to verify if the protected device being        used is a genuine one and not a counterfeit/overbuilt part. On        successful verification of the protected device and the details        of the use provided by the protected device user, the IP owner        will issue an authentication key to the protected device user,        which is required to unlock the functionality of the protected        device. The IP owner may employ an automated authentication        provisioning subsystem 422, executing on a secure computing        system 420, to perform the authentication process. In another        embodiment, this automated authentication process can also be        implemented as a secure hardware module to be integrated with        other IP owner hardware functionality on the provisioning end.    -   The Device User, who is in possession of the protected        electronic device and needs to unlock the functionality of the        protected device for use on a particular system/board. The        device user can request a secure data communication connection        with the IP owner for protected device authentication. In        return, the requesting device node 410 of the device user can be        prompted by the authentication provisioning node 420 of the IP        owner to provide identification and usage details of the        protected device. These identification and usage details can        include, for example, the details of the system/board with which        the protected device is going to be paired, an identification of        the device user, an identification of the protected device, an        identification of the system/board, and any certifications or        credentials needed to prove the genuineness of the protected        electronic device procurement.

Referring still to FIGS. 5 through 8, an example embodiment illustratesthe processing operations performed as part of the authenticationprotocol. The authentication protocol provides a data interactionbetween the IP owner and the protected device user. This informationexchange is done securely using the conventional and establishedInternet access protocols (e.g., SSL/TLS). However, the data interactionand the information exchanged as part of the authentication protocol isan innovative authentication process. At the conclusion of theinformation exchange, based on the information provided as part of theauthentication protocol, the IP owner node 420 makes a trust evaluationof the protected device user, the protected device itself, and thesystem/board with which the protected device is to be paired. Onsuccessful evaluation of the trust details, the IP owner provides anencrypted authentication key to the protected device user. The protecteddevice user programs this authentication key into the protected device.The pertinent details of the authentication protocol of an exampleembodiment are described below as illustrated by the processing flowdiagrams of FIGS. 5 through 8.

Referring now to FIG. 5 of an example embodiment, a processing flowdiagram illustrates the processing performed in the example embodimentfor the first-time pairing of the protected device with a specificsystem or board. In the case of the first-time pairing of the protecteddevice with a specific system or board, the protected device is firstpowered-on on the new specific system/board. A data communication isopened between the Requesting Device Node (RDN) and the AuthenticationProvisioning Node (APN) (processing block 502). The RDN sends a securemessage to the APN requesting device authentication (processing block503). The RDN receives a secure message from the APN in response to theauthentication request message, requesting a specific system/boardidentifier (processing block 504). The RDN reads the specificsystem/board identifier from the system/board (processing block 505).The RDN sends a secure message to the APN with the system/boardidentifier (processing block 506). The RDN receives a secure messagefrom the APN requesting a protected device identifier (processing block507). The RDN reads the protected device identifier from the protecteddevice (processing block 508). The RDN sends a secure message to the APNwith the device identifier (processing block 509). The RDN can also sendadditional secure messages to the APN with other user information,device information, or other system credentials or certificates(processing block 510). The RDN receives a secure message from the APNrequesting a protected device query packet (processing block 511). Thecontent of the device query packet in an example embodiment is describedin more detail below in connection with FIG. 9. The RDN reads and/orassembles the device query packet from the protected device (processingblock 512). The RDN sends a secure message to the APN with the devicequery packet (processing block 513). Processing for the exampleembodiment continues at the bubble 521 shown in FIG. 6 where the IPowner verifies the trust of the protected device user and theauthentication key for the protected device is generated.

Referring now to FIGS. 6 and 7 of an example embodiment, a processingflow diagram 521 illustrates the processing performed by the APN, in theexample embodiment for the protected device user trust verification andthe authentication key generation. As shown in FIG. 6, the APN receivesa secure message from the RDN requesting an authentication key(processing block 522). The APN can extract a protected deviceidentifier and a board/system identifier from the secure message. TheAPN can check the device identifier for a spurious or disqualified part(processing block 524). The APN can perform a test at decision block 526to determine if the requesting device is a spurious or disqualified partbased on the device identifier and the board/system identifier. If thetest performed at decision block 526 is true (yes), the APN can send asecure message to the RDN indicating that the authentication key requestis denied and can terminate further authentication processing(processing block 528), pending direct sideband interaction between theprotected device user and the IP owner. If the test performed atdecision block 526 is false (no), the APN can transition to decisionblock 530. At decision block 530, the APN can test if the deviceidentifier of the protected device is unique. If the test performed atdecision block 530 is true (yes), the APN can increment a device countfor this device model (processing block 532) and processing cantransition to decision block 536. If the test performed at decisionblock 530 is false (no), processing can transition to decision block534. At decision block 534, the APN can test if the requesting devicehas already been authenticated. If the test performed at decision block534 is true (yes), processing can transition to processing block 542. Ifthe test performed at decision block 534 is false (no), the APN cancontinue processing at the continuation block A 550 shown in FIG. 7 anddescribed below.

When the processing at processing block 532 is complete, processingtransitions to decision block 536. A test is performed at decision block536 to determine if the device count has exceeded a pre-determinedmaximum value of devices agreed for production. If the test performed atdecision block 536 is true (yes), processing can transition toprocessing block 542. If the test performed at decision block 536 isfalse (no), processing can transition to decision block 538. At decisionblock 538, the APN can test if the security certifications andcredentials given to it for the protected device and the specificsystem/board are valid. If the test performed at decision block 538 istrue (yes), processing can transition to processing block 540. If thetest performed at decision block 538 is false (no), processing cantransition to processing block 542.

At processing block 542, the request for a new authentication key forthe requesting device is declined and authentication processingterminates. The next step to enable a future authentication processrequires direct sideband interaction between the protected device userand the IP owner. At processing block 540, on the APN side, for thisdevice identifier, first an Authentication Attempt Count is initializedto a value of one, and also an Authentication Time Window value isprogrammed. Next, the request for a new authentication key for therequesting device is granted and the new authentication key for therequesting device user is generated. Processing then terminates at theEnd bubble shown in FIG. 6.

If the test performed at decision block 534 shown in FIG. 6 is false(no), the requesting device identifier is not unique and the requestingdevice has not been previously authenticated. In this case, processingcontinues at the continuation block A 550 shown in FIG. 7 and describednext. Referring now to FIG. 7, processing continues for the protecteddevice user trust verification and the authentication key generation inan example embodiment. A test is performed at decision block 552 todetermine if the requesting device has been previously matched to adifferent board or system. If the test performed at decision block 552is true (yes), processing can transition to processing block 556. If thetest performed at decision block 552 is false (no), processing cantransition to processing block 554. At processing block 554, an attemptcount is incremented to keep track of the number of times authenticationfor the protected device has been attempted. At processing block 556,additional trust credentials for the requesting device are requestedfrom the RDN. When the processing at processing block 554 is complete, atest is performed at decision block 558 to determine if theauthentication attempt count has been exceeded or the authenticationtime window has expired. If the test performed at decision block 558 istrue (yes), processing can transition to processing block 564. If thetest performed at decision block 558 is false (no), processing cantransition to processing block 562.

When the processing at processing block 556 is complete, a test isperformed at decision block 560 to determine if the requesting devicesecurity certifications and credentials are valid. If the test performedat decision block 560 is true (yes), processing can transition via thecontinuation block B 561 to processing block 540 as shown in FIG. 6 anddescribed above. If the test performed at decision block 560 is false(no), processing can transition to processing block 564 as shown in FIG.7.

At processing block 564, the request for a new authentication key forthe requesting device is declined and authentication processingterminates. The next step to enable a future authentication processrequires direct sideband interaction between the protected device userand the IP owner. At processing block 562, the request for a newauthentication key for the requesting device is granted and the newauthentication key for the requesting device user is generated.Processing then terminates at the End bubble shown in FIG. 7.

Referring now to FIG. 8 of an example embodiment, a processing flowdiagram illustrates the processing performed in the example embodimentfor validation and insertion of the authentication key into theprotected device. The insertion or programming of a valid authenticationkey into the protected device will unlock and enable the functionalityof the protected device on the particular system/board. In processingblock 572, the RDN receives a secure message from the APN with theencrypted authentication key packet. The details of the authenticationkey packet are described below in connection with FIG. 9. The RDNreceives the encrypted authentication key packet after successfullysatisfying all of the verification and credentialing checks describedabove in connection with FIGS. 5 through 7. Upon receipt of theencrypted authentication key packet from the APN, the RDN can decryptthe encrypted authentication key packet and start the process ofprogramming the authentication key into the protected device (processingblock 573). The details of programming the authentication key into theobfuscation state machine of the protected device are described above inconnection with FIG. 3. As part of the process of starting to programthe authentication key into the protected device, the device hardwarecan unwrap the authentication key received from the APN and check to seeif the individual fields of the authentication key are within theacceptable limits. If the authentication key information is notacceptable, a message will be presented to the protected device userconveying information related to the authentication failure (e.g., ahardware error code can be output, which is interpreted by the securedevice driver as a message for the protected device user, the messageincluding the reasons for the failure). Upon authentication key failure,the protected device will continue to remain in the obfuscated,non-functional state. The protected device user may make the necessarycorrections and initiate another authentication request to the IPowner/APN.

If the authentication key information received from the APN isacceptable, the internal protected device hardware can set a flag toindicate that a successful authentication of the protected device by theIP owner is achieved. This flag called, “Valid Authentication KeyProgrammed” is set internally on the control event of successfulauthentication key verification by the protected device. This flag willnot be reset on any kind of protected device hardware or software reset.This flag will remain persistent across power-downs/ups and boots of thesystem/board paired with the protected device. This persistence isachieved by storing the flag value externally to the protected device aspart of an encrypted image in secure BIOS, a Tamper Resistance Flash(TRF) device, or in an existing on-board/system Trusted Platform Module(TPM) (processing block 574). In processing block 574, the validatedauthentication key can also be modified by the protected device hardwareby replacing the unique nonce timestamp with a safe, acceptable pattern.In one embodiment this replaced portion can be bit values from randomlychosen bit locations of the device's first portion of the obfuscationcode (derived from the device unique embedded n parameter bits). Otherembodiments can choose other approaches to modify the Authentication keyvalue before secure storage. The rest of the authentication key canremain the same. The modified authentication key can also be storedexternally to the protected device in an encrypted fashion. Forsubsequent power-on and re-boot cycles, the protected device can firstfetch the “Valid Authentication Key Programmed” flag from externalsecure storage. If the protected device determines that the fetched“Valid Authentication Key Programmed” flag is asserted (true), theprotected device can then fetch the securely stored authentication keyas well. As a result, the protected device can proceed without the needfor an extensive authentication exchange with the IP owner forsubsequent power-on and re-boot cycles, once the authentication issuccessfully achieved on the very first pairing of the protected devicewith a new system/board. After a successful authentication of theprotected device as paired with the particular system/board as describedabove, the protected device internal hardware can perform a procedure tounlock the obfuscated, non-functional protected device and transitionthe protected device to a non-obfuscated, fully functional state(processing block 575). The details of programming the authenticationkey into the obfuscation state machine of the protected device aredescribed above in connection with FIG. 3. The action of programming thevalid authentication key into the obfuscation state machine of theprotected device serves to unlock the obfuscated, non-functionalprotected device and transition the protected device to anon-obfuscated, fully functional state. Processing then terminates atthe End bubble shown in FIG. 8.

Referring now to FIG. 9, in an example embodiment, the data structuresof the exchanged device specific authentication information areillustrated. In the example embodiment, there are two basic deviceauthentication data packets, the authentication query packet and theauthentication response data packet, which are associated with theprotected device user/the protected device, and the IP owner,respectively. In the example embodiment, the authentication query datapacket is denoted the device query packet. In the example embodiment,the authentication response data packet is denoted the authenticationkey data packet. The specifics of these data packets are described inmore detail below for the example embodiment. These data packets aresecurely exchanged between the RDN and the APN in the authenticationprotocol as described above.

Device Query Packet:

In the example embodiment, this is the final packet provided by the RDNand is an encrypted 128 bits, which the RDN will provide to the APN.Prior to this packet transfer as described above, the RDN will transmitto the APN, using existing secure Internet Protocols (SSL/TLS), theindividual components of the device and system identifying informationincluding, a protected device identifier (ID), system/board ID, andother trust credentials, which the IP owner requires from the RDN. Theencrypted device query packet is created by the protected device. In theexample embodiment, the device query packet is assembled, as shown inFIG. 9, with a 96 bit nonce stamp (e.g., value) to defeat packet replayattacks. The nonce value can be generated through a combination ofprotected device embedded real random number generators andpseudo-random number generators along with device-based entropies forseeding. The 31 bit obfuscation state is generated by the protecteddevice, and based on the unique device ID-based value of the protecteddevice. The 31 bit obfuscation state value corresponds to the unique perdevice power-on non-functional state in which the protected device wakesup on power-up or reboot. The least significant bit (LSB) of the devicequery packet is a one bit “Authentication Done” indicator, which ispersistent across re-boot and power-on cycles of the protected device onthe same system/board. The “Authentication Done” indicator is aprotected device internal value, which keeps track of the protecteddevice having been successfully authenticated before.

Authentication Key Packet:

In the example embodiment, this packet represents the encryptedauthentication key generated by the APN on the successful outcome of theprotected device/protected device user trust verification performed bythe APN as part of the authentication protocol as described above. Theauthentication key packet has the same 96 bit nonce value to match withthe device query packet, and thus defeats replay attack attempts. TheAPN can generate the N bit authorization code value as shown in FIG. 9,which the protected device checks to see if the value is indeed anacceptable value. The (32-N) bit value field, as shown in FIG. 9,defines the specific number of cycles close to which the protecteddevice should always take to converge from its non-functional obfuscatedstate to its first functional state. This value is a performance metric,and in the absence of a given value, a default number of cycles isassumed by the protected device to achieve its convergence to anon-obfuscated, fully functional state. It will be apparent to those ofordinary skill in the art in view of the disclosure herein thatadditional values or different arrangements of data in the device querypacket and the authentication key packet can be implemented within thescope of the embodiments described herein.

Referring now to FIG. 10, a processing flow diagram illustrates anexample embodiment of a method 1150 as described herein. The method 1150of the example embodiment includes: providing a protected device(processing block 1160); generating a device query packet including datarepresenting one or more identifiers of the protected device and aparticular paired system (processing block 1162); obtaining anauthentication key based on the device query data packet from anauthentication provisioning node using an external data communication(processing block 1164); and programming an obfuscation state machine ofthe particular paired system with the authentication key to cause theobfuscation state machine to transition the protected device from aninitial non-functional obfuscation state to a functional state(processing block 1166).

Non-Functional to Functional State Machine Transition in an ExampleEmbodiment

In example embodiments described herein, systems and methods aredisclosed for causing an obfuscated non-functional device to transitionto a starting functional state using a specified number of cycles.Referring now to FIGS. 11 through 14, processing flow diagramsillustrate an example embodiment of a method 1201 as described herein.In the described example embodiment, a protected electronic device, suchas the functional/operational system 330 described above, can beimplemented with the systems and methods described below as integratedwith or embedded within the design of the embedded active obfuscationunit 300 as described herein in various embodiments. Control logicwithin the obfuscation unit 300 and/or within the protected electronicdevice 330 can be used to implement the processing and data operationsas described below.

Referring now to FIG. 11 at processing block 1210 for an exampleembodiment, the protected electronic device can be initially powered upin a protected state. On power-on in the protected state, the protectedelectronic device can initially use the on-device PUF component 310 andECC circuitry 312 as described above to generate a device-unique seedvalue that is P bits long (or wide). Alternatively, the protectedelectronic device can initially use an already randomly programmed fusevector or another form of seed value source to obtain the P bitdevice-unique seed value. In a particular embodiment, P can be a valuegreater than 64 bits, such as an 84 bit unique-per-device value. This Pbit seed value is always consistent and can be automatically generatedand/or retrieved on initial power-on of the protected electronic device.This P bit seed value is the root of trust for the protected electronicdevice in terms of its use for seeding all other protected electronicdevice-specific parameters used in the secure initialization processdescribed herein for the various embodiments.

At processing block 1220 for the example embodiment shown in FIG. 11,the protected electronic device can derive K bits from a randomlypositioned set of bits from the P bits of the seed value, where K istypically greater than 16 bits (processing block 1220). As describedabove, the K bits can be derived from randomly designed/hardwiredlocations of the on-device PUF component 310, ECC circuitry 312, arandomly programmed fuse vector, or another form of seed value source.The K bits can be used to define the initial (e.g., the original,starting, or wakeup) obfuscation state of the protected device. Inparticular embodiments, K can be in the range of 22 to 32 bits (defaultvalue 22 bits) to provide a total state count between 4 million (2²²) to4 billion (2³²) total states in the state machine 320. Then, the exampleembodiment can load K state elements (e.g., flops) of the state machine320 with values corresponding to the K bits derived from the seed value(processing block 1230). The K state elements will represent the initialobfuscation state. The example embodiment can then use a differentrandomly positioned set of bits from the P bits of the seed value toderive a different set of M bits, which is then used in the creation ofthe Starting Functional Reset State Value (processing block 1240). In atypical implementation, the value of M is much less than the values of Kor P. This will ensure that the Starting Functional Reset State iswell-hidden in a much greater number of obfuscation states. For example,an order of magnitude larger K compared to M will yield a six to eightorders of magnitude difference between the total number of states in thestate machine 320 compared with the total number of functional states.In a particular example with M equal to two bits and K equal to an orderof magnitude larger number of bits (e.g., K=2×10=20 bits), the totalnumber of states will be one million (2²⁰) states compared to the totalnumber of functional states, which in this example would be four (2²),which is a difference of six orders of magnitude. Similarly, with M=3,and K=30 (e.g., 3×10=30, an order of magnitude greater than M), thetotal number of states in the state machine 320 would be one billionstates)(2³⁰) compared to the total number of functional states, which inthis example would be eight (2³), which is a difference of greater thaneight orders of magnitude.

Once the example embodiment has derived M bits from a randomlypositioned set of bits from the P bits of the seed value, the exampleembodiment can create the Starting Functional Reset State Value asinfluenced by these M bits (processing block 1250). Another way toexplain this is that the M bits underpinning the Starting FunctionalReset State Value will be scattered into random bit positions in a new Kbit wide vector, with rest of the (K-M) bit locations having a specialrelationship with the original K bits scoping the entire ObfuscationState machine. The value of the M bits chosen, combined with the rest ofthe associated K bit vector, produces the location of the StartingFunctional Reset State in the state transition graph (STG) in a mannerthat is completely unique for each device. The example embodiment cansave the Starting Functional Reset State Value, which is unique to eachprotected electronic device (processing block 1260). Each of theremaining functional states in the state machine 320 can be created by afixed incremental and sequential delta offset from the StartingFunctional Reset State Value. Such offset value can itself be derivedfrom the original P bits wide seed value. This makes the locations ofall the functional states also unique per device, as each of theseremaining functional states are based on the device-unique randomStarting Functional Reset State Value. Once the Starting FunctionalReset State Value is generated as described above, the exampleembodiment can proceed, via the connection block 1270, to the processinglogic shown in FIG. 12, where the states in the state machine 320 aretraversed from the initial non-functional obfuscation state to theStarting Functional Reset State.

As described above, the authentication protocol, of an exampleembodiment described herein, can use a full handshake protocol between auser of the protected electronic device and the IP owner of theprotected electronic device to provision the authentication of theprotected electronic device in a particular electronic system. Asuccessful authentication handshake between the user of the protectedelectronic device using the device in the particular electronic systemfor the very first time and the IP owner of the protected electronicdevice leads to the encrypted authentication key being programmed intothe protected electronic device as described above. As part of thisauthentication protocol handshake transaction, the IP owner can specifya value corresponding to the, “Number of clock cycles to reach theFunctional State.” This value enables the IP owner to specify a level ofprotection or obfuscation for concealing the Starting Functional ResetState among a large set of obfuscation states. As a result, the IP ownercan be assured that his/her IP will be well protected. This value can bespecified as part of the Authentication Key field as described above(e.g., see FIG. 9). This value is typically a power of two and istypically not less than 256. In a particular embodiment, the value canrepresent a number of cycles or state transitions between 256 and 4096.As described in more detail below, the example embodiment is configuredto cycle through the states of state machine 320 from an initialobfuscation state to the Starting Functional Reset State in a number ofcycles or state transitions that corresponds to the “Number of clockcycles to reach the Functional State” value as specified by the IPowner. In some embodiments, the actual number of state transitions mayvary from the specified number by at most one cycle/state transition.

Referring now to FIG. 12 at processing block 1211 for the exampleembodiment, processing continues, via the connection block 1270, towhere the initialization of a process is performed, wherein the processis for traversing states in the state machine 320 from the initialnon-functional obfuscation state to the Starting Functional Reset State.As described above, the “Number of clock cycles to reach the FunctionalState” value as specified by the IP owner can be retrieved from thecorresponding Authentication Key field. This value can be used in theexample embodiment to determine the actual number of clock cycles ortraversal cycles needed to traverse states to reach the StartingFunctional Reset State (processing block 1211). This value can also beused in the example embodiment to initialize a total state range value(processing block 1211). In some cases, the actual number of clockcycles used for state traversal can be modified from the value specifiedby the IP owner to accommodate the particular characteristics of aspecific state machine or device. A specific state machine can oftenprovide a particular quantity of state elements or states, wherein thequantity may vary from device to device. As a result, the total quantityof state elements and the corresponding total state range value can bedetermined for the specific state machine or device in processing block1211. Using the programmed “Number of clock cycles to reach FunctionalState” value, the example embodiment can compute a number of the statetransitions needed to reach the Starting Functional Reset State anddetermine the Obfuscated State Start position in the total state range(processing block 1211). Based on the total quantity of states in thespecific state machine (e.g., 2^(K)) and the total number of cyclesdetermined to complete the traversal from an initial obfuscation stateto the Starting Functional Reset State (e.g., 2^(N)), a state jumpinterval can be determined for reaching the Starting Functional ResetState in the programmed number of clocks (processing block 1221). In theexample embodiment, the state machine state traversal process is basedon the premise that the quantity of cycles used or states traversed toreach the end or extremity of the state value range of the state machinefrom the starting point of the initial obfuscation state should be thesame or similar to the “Number of cycles to reach Functional State”value provided by the IP Owner.

As described above, the K bits randomly taken from PUF component 310,ECC circuitry 312, a randomly programmed fuse vector, or another form ofseed value source are used to define the initial obfuscation state ofthe protected device. Because this K bit obfuscation state value israndomly obtained, the value can either be in the upper half or thelower half of the entire state value range of the state machine. Bydetermining whether the obfuscation state value is in the upper or lowerhalf of the state value range, the state machine state traversal processcan be configured to operate in either a forward or backward traversaldirection. The K bit obfuscation state value can be analyzed todetermine if the value is in the upper or lower range. If theobfuscation state value is in the lower half of the state value range,then forward state traversal is performed to the end of the state valuerange by skipping a “Number of states to be skipped” count of states oneach cycle, until close to the end of the state value range is reached.If the obfuscation state value is in the upper half of the state valuerange, then backward state traversal of the state machine is performedusing the “Number of states to be skipped” count on each statetransition, until close to the beginning of the state value range isreached. Once the extremities of the state range are traversed asdescribed above, the state machine is configured to start at the initialobfuscation state. From this starting point, the state traversal isperformed in the opposite direction (i.e., backward or forward) ascompared with the earlier traversal direction. The state traversalprocess is continued in the opposite direction until the opposite end ofthe state range is reached. Once the opposite end of the state range isreached, the state traversal through the states of the state machine asrequired to be done using the number of clock cycles specified iscompleted.

Referring still to FIG. 12 at processing block 1231 for the exampleembodiment, processing continues by setting a Convergence Windowindicator to active (processing block 1231). In some cases, during thestate traversal operation, it is possible that a functional state may betraversed before the state machine reaches the Starting Functional ResetState. In these cases, the example embodiment is configured to disablethe activation of these traversed functional states prior to reachingthe Starting Functional Reset State. The Convergence Window indicator isused for this purpose. The Convergence Window indicator is set to activein processing block 1231 prior to initiating the state traversaloperation and remains active prior to reaching the Starting FunctionalReset State. As a result, an internal mode is set to indicate that theprotected electronic device is in an“Obfuscation-State-to-First-Functional-State Convergence Window”operational status. During this operational status or window, allfunctional states of the state machine 320 continue to remain inactive.At processing block 1241, a Current State value is initialized to theinitial obfuscation state value from the device-unique seed value. Thisoperation effectively places the state machine 320 in the initialobfuscation state from which the state traversal process in statemachine 320 can begin. At processing block 1251, a loop is initiated totransition from the initial obfuscation state to the Starting FunctionalReset State by traversing the states of state machine 320. Processingthen continues, through connection block 1261 shown in FIG. 13, wherethe state traversal operation is performed.

Referring now to FIG. 13 at connection block 1261 for the exampleembodiment, processing continues to decision block 1212. At decisionblock 1212, the Current State is tested to determine whether the currentstate has reached modulo—the end of the total state range of the statemachine. As described above, traversal of the state machine is performeduntil the current state reaches the extremity of the state value range.If the Current State is not within modulo—the end of the total staterange of the state machine, processing continues at decision block 1212as the obfuscated states are traversed. When the Current State is withinmodulo—the end of the total state range of the state machine, processingcontinues at processing block 1222 where the state transitions areconfigured to be traversed in the opposite direction (processing block1222). If the Current State is not within modulo—the other end of thetotal state range of the state machine, processing continues at decisionblock 1252 as the obfuscated states are traversed in the oppositedirection. When the Current State is within modulo—the other end of thetotal state range of the state machine, processing continues atprocessing block 1262 where the state traversal process is complete. Atprocessing block 1262, the Convergence Window indicator is reset toInactive (processing block 1262). The resetting of the ConvergenceWindow indicator enables the activation and operation of all functionalstates of the state machine when a traversal reaches a functional state.Once the state machine traversal is complete as described above, thestate machine is configured to start at the Starting Functional ResetState. In this case, the protected electronic device has been fullyauthenticated and authorized to proceed from the starting functionalreset state in a normal operational mode. At processing block 1272, theinitialization of the protected electronic device can proceed from theStarting Functional Reset State. Thus, a system and method to cause anobfuscated non-functional device to transition to a starting functionalstate using a specified number of cycles is disclosed.

Referring now to FIG. 14, a processing flow diagram illustrates anexample embodiment of a method 1450 as described herein. The method 1450of the example embodiment includes: providing a protected electronicdevice having an embedded obfuscation unit including an obfuscationstate machine (processing block 1460); obtaining a randomized seed value(processing block 1462); extracting a first number of bits from therandomized seed value, the first number of bits representing an initialobfuscation state (processing block 1464); extracting a second number ofbits from the randomized seed value, the second number of bitsrepresenting a starting functional reset state (processing block 1466);determining a number of traversal cycles needed to traverse throughstates of the obfuscation state machine from the initial obfuscationstate to the starting functional reset state (processing block 1468);and initiating a state traversal operation to traverse through states ofthe obfuscation state machine from the initial obfuscation state to thestarting functional reset state in the determined number of traversalcycles (processing block 1470).

It will be apparent to those of ordinary skill in the art in view of thedisclosure herein that the method steps or processing operationsdescribed above may be performed in alternative sequences. For example,another alternative embodiment may use the obfuscation code to requestan authentication key from an authorized representative in a firstexternal communication and then may use the board/system identifier datato request the authentication key from the authorized representative ina second external communication.

FIG. 15 shows a diagrammatic representation of a machine in the exampleform of an electronic device, such as a computing and/or communicationsystem 700 within which a set of instructions when executed and/orprocessing logic when activated may cause the machine to perform any oneor more of the methodologies described and/or claimed herein. Inalternative embodiments, the machine operates as a standalone device ormay be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aclient machine in server-client network environment, or as a peermachine in a peer-to-peer (or distributed) network environment. Themachine may be a personal computer (PC), a laptop computer, a tabletcomputing system, a Personal Digital Assistant (PDA), a cellulartelephone, a smartphone, a web appliance, a set-top box (STB), a networkrouter, switch or bridge, or any machine capable of executing a set ofinstructions (sequential or otherwise) or activating processing logicthat specify actions to be taken by that machine. Further, while only asingle machine is illustrated, the term “machine” can also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions or processing logic to performany one or more of the methodologies described and/or claimed herein.

The example mobile computing and/or communication system 700 includes adata processor 702 (e.g., a System-on-a-Chip [SoC], general processingcore, graphics core, and optionally other processing logic) and a memory704, which can communicate with each other via a bus or other datatransfer system 706. The mobile computing and/or communication system700 may further include various input/output (I/O) devices and/orinterfaces 710, such as a display device or network interface 712. In anexample embodiment, the network interface 712 can include one or moreradio transceivers configured for compatibility with any one or morestandard wireless and/or cellular protocols or access technologies(e.g., 2nd (2G), 2.5, 3rd (3G), 4th (4G) generation, and futuregeneration radio access for cellular systems, Global System for Mobilecommunication (GSM), General Packet Radio Services (GPRS), Enhanced DataGSM Environment (EDGE), Wideband Code Division Multiple Access (WCDMA),LTE, CDMA2000, WLAN, Wireless Router (WR) mesh, and the like). Networkinterface 712 may also be configured for use with various other wiredand/or wireless communication protocols, including TCP/IP, UDP, SIP,SMS, RTP, WAP, CDMA, TDMA, UMTS, UWB, WiFi, WiMax, Bluetooth, IEEE802.11x, and the like. In essence, network interface 712 may include orsupport virtually any wired and/or wireless communication mechanisms bywhich information may travel between the computing and/or communicationsystem 700 and another computing or communication system via network714.

The memory 704 can represent a machine-readable medium on which isstored one or more sets of instructions, software, firmware, or otherprocessing logic (e.g., logic 708) embodying any one or more of themethodologies or functions described and/or claimed herein. This alsoincludes Tamper Resistant Flash (TRF) and Trusted Platform Modules(TPM). The logic 708, or a portion thereof, may also reside, completelyor at least partially within the processor 702 during execution thereofby the mobile computing and/or communication system 700. As such, thememory 704 and the processor 702 may also constitute machine-readablemedia. The logic 708, or a portion thereof, may also be configured asprocessing logic or logic, at least a portion of which is partiallyimplemented in hardware or firmware. The logic 708, or a portionthereof, may further be transmitted or received over a network 714 viathe network interface 712. While the machine-readable medium of anexample embodiment can be a single medium, the term “machine-readablemedium” should be taken to include a single non-transitory medium ormultiple non-transitory media (e.g., a centralized or distributeddatabase, and/or associated caches and computing systems) that store theone or more sets of instructions. The term “machine-readable medium” canalso be taken to include any non-transitory medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of the various embodiments, or that is capable of storing,encoding or carrying data structures utilized by or associated with sucha set of instructions. The term “machine-readable medium” canaccordingly be taken to include, but not be limited to, solid-statememories, optical media, and magnetic media.

With general reference to notations and nomenclature used herein, thedescription presented herein may be disclosed in terms of programprocedures executed on a computer or a network of computers. Theseprocedural descriptions and representations may be used by those ofordinary skill in the art to convey their work to others of ordinaryskill in the art.

A procedure is generally conceived to be a self-consistent sequence ofoperations performed on electrical, magnetic, or optical signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. These signals may be referred to as bits, values, elements,symbols, characters, terms, numbers, or the like. It should be noted,however, that all of these and similar terms are to be associated withthe appropriate physical quantities and are merely convenient labelsapplied to those quantities. Further, the manipulations performed areoften referred to in terms such as adding or comparing, which operationsmay be executed by one or more machines. Useful machines for performingoperations of various embodiments may include general-purpose digitalcomputers or similar devices. Various embodiments also relate toapparatus or systems for performing these operations. This apparatus maybe specially constructed for a purpose, or it may include ageneral-purpose computer as selectively activated or reconfigured by acomputer program stored in the computer. The procedures presented hereinare not inherently related to a particular computer or other apparatus.Various general-purpose machines may be used with programs written inaccordance with teachings herein, or it may prove convenient toconstruct more specialized apparatus to perform methods describedherein.

The Abstract of the Disclosure is provided to allow the reader toquickly ascertain the nature of the technical disclosure. It issubmitted with the understanding that it will not be used to interpretor limit the scope or meaning of the claims. In addition, in theforegoing Detailed Description, it can be seen that various features aregrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter lies in less than allfeatures of a single disclosed embodiment. Thus, the following claimsare hereby incorporated into the Detailed Description, with each claimstanding on its own as a separate embodiment.

What is claimed is:
 1. An electronic system comprising: a protectedelectronic device; and an embedded obfuscation unit coupled with theprotected electronic device, the embedded obfuscation unit including anobfuscation state machine, the embedded obfuscation unit furtherincluding control logic to: obtain a randomized seed value; extract afirst number of bits from the randomized seed value, the first number ofbits representing an initial obfuscation state; extract a second numberof bits from the randomized seed value, the second number of bitsrepresenting a starting functional reset state; determine a number oftraversal cycles needed to traverse through states of the obfuscationstate machine from the initial obfuscation state to the startingfunctional reset state; and initiate a state traversal operation totraverse through states of the obfuscation state machine from theinitial obfuscation state to the starting functional reset state in thedetermined number of traversal cycles.
 2. The electronic system of claim1 wherein the randomized seed value is obtained from a PhysicallyUnclonable Function (PUF) device, an error correcting code logic (ECC)device, or a randomly programmed fuse vector.
 3. The electronic systemof claim 1 wherein the first number of bits is greater than the secondnumber of bits.
 4. The electronic system of claim 1 wherein the firstnumber of bits is an order of magnitude greater than the second numberof bits.
 5. The electronic system of claim 1 wherein the control logicbeing further configured to determine the number of traversal cycles byextracting a value from an authentication key field of an authenticationkey packet.
 6. The electronic system of claim 1 wherein the controllogic being further configured to determine a total quantity of stateelements and a corresponding total state range value of the obfuscationstate machine.
 7. The electronic system of claim 1 wherein the controllogic being further configured to determine if the initial obfuscationstate is in an upper half or a lower half of an entire state value rangeof the obfuscation state machine.
 8. The electronic system of claim 1wherein the control logic being further configured to initiate a statetraversal operation in a forward or backward direction.
 9. Theelectronic system of claim 1 wherein the control logic being furtherconfigured disable activation of traversed functional states prior toreaching the starting functional reset state.
 10. A method comprising:providing a protected electronic device having an embedded obfuscationunit including an obfuscation state machine; obtaining a randomized seedvalue; extracting a first number of bits from the randomized seed value,the first number of bits representing an initial obfuscation state;extracting a second number of bits from the randomized seed value, thesecond number of bits representing a starting functional reset state;determining a number of traversal cycles needed to traverse throughstates of the obfuscation state machine from the initial obfuscationstate to the starting functional reset state; and initiating a statetraversal operation to traverse through states of the obfuscation statemachine from the initial obfuscation state to the starting functionalreset state in the determined number of traversal cycles.
 11. The methodof claim 10 wherein the randomized seed value is obtained from aPhysically Unclonable Function (PUF) device, an error correcting codelogic (ECC) device, or a randomly programmed fuse vector.
 12. The methodof claim 10 wherein the first number of bits is greater than the secondnumber of bits.
 13. The method of claim 10 wherein the first number ofbits is an order of magnitude greater than the second number of bits.14. The method of claim 10 including determining the number of traversalcycles by extracting a value from an authentication key field of anauthentication key packet.
 15. The method of claim 10 includingdetermining a total quantity of state elements and a corresponding totalstate range value of the obfuscation state machine.
 16. The method ofclaim 10 including determining if the initial obfuscation state is in anupper half or a lower half of an entire state value range of theobfuscation state machine.
 17. The method of claim 10 includinginitiating a state traversal operation in a forward or backwarddirection.
 18. The method of claim 10 including disabling activation oftraversed functional states prior to reaching the starting functionalreset state.